I don’t know about you, but I get pretty determined to prove them wrong when people tell me that I cannot do something. I am not talking about fantastical things such as flying through the heart of the sun and out the other side without getting burned. Nor, am I talking about social things like becoming president of the United States or an author on the New York Times Bestseller list. And, I am not talking about physical things such as swimming 2.4 miles, biking 112 miles, and running 26.2 miles back-to-back on the same day. No, I am talking about being told that I cannot do something with SAS.
For example, I was once told:
- that you could not summarize impossibly large SAS data sets to load a data warehouse. So, I figured out a way to do it.
- that you could not measure the performance of SAS/IntrNet application programs. So, I figured out a way to do it.
- that you could not determine which SAS products individual staff members were using on shared servers. So, I figured out a way to do it.
- that you could not create a chargeback system for UNIX and Linux systems without purchasing an accounting package. So, I figured out a way to do it.
Consequently, when I was told that there was no SAS facility for programmatically determining whether a Windows SAS catalog was a 32-bit catalog or a 64-bit catalog, I resolved to figure out a way to do it.
The background is that my organization plans to migrate from 32-bit SAS to 64-bit SAS as part of a SAS 9.3 to SAS 9.4 upgrade. SAS data sets are compatible between the two bitages, but SAS catalogs are not. Stating the problem: you cannot open a 64-bit SAS catalog with 32-bit SAS. So, it is advantageous to have a tool for determining which SAS catalog is which bitage as you move forward into a mixed-bit programming environment during the transition.
I did my due diligence and researched every place that I thought I might be able to find a way to differentiate the bitage. An indicator in PROC CATALOG if I ran it with the STAT option enabled? Nope. Something in the directory portion of a PROC CONTENTS listing with the DETAILS option specified? Nope. A lesser-known option of PROC DATASETS? Nope. How about a flag in the Dictionary Tables CATALOGS table or in the SASHELP Views VCATALG view? Nope. A Usage Note on support.sas.com. Nope. A SAS technical paper published at either SAS Global Forum or a Regional SAS Users Group? Nope, not that either.
I figured that if you could not tell the difference within SAS, itself, how about if you looked at the catalogs as simply files. So, I got a 32-bit SAS catalog and a 64-bit SAS catalog and opened them with WordPad to take a look inside. Bingo! There was enough information in the very first record of both catalog files to determine the difference. So, I wrote a program that tested for the string of characters that told the tale.
Here is the SAS program that I wrote:
/*Macro to determine bitage of a SAS catalog */ %MACRO Test_Cat_Bitage(SASCatalog); filename sascat "&SASCatalog"; data decompcat(keep=CAT_BITS SAS_Catalog); length CAT_BITS $8 SAS_Catalog $50; infile sascat obs=1 truncover; input bigline $charzb32767. ; if index(bigline, "W32_7PRO") > 0 then CAT_BITS = "W32_7PRO"; else if index(bigline, "X64_7PRO") > 0 then CAT_BITS ="X64_7PRO"; else CAT_BITS = "Unknown "; SAS_Catalog = strip("&SASCatalog"); label CAT_BITS = "Bitage of SAS Catalog" SAS_Catalog = "Full Path SAS Catalog Name" ; run; proc append base=AllCatalogs data=decompcat; run; %MEND Test_Cat_Bitage; /* Example of executing the macro to read a catalog file */ %Test_Cat_Bitage(c:\temp\gender.sas7bcat); |
As you can see, the program determines the bitage of a SAS catalog by treating the catalog as a file, not as a catalog. It opens the catalog file and inspects the first line for a specific character string: W32_7PRO for 32-bit catalogs; X64_7PRO for 64-bit catalogs. Once it determines the bitage, the program writes an observation to data set AllCatalogs in the WORK library. Each observation in AllCatalogs has two variables: CAT_BITS, which specifies whether the catalog is 32 or 64 bits, and SAS_Catalog, which is the full path name of the SAS catalog file.
The object of this particular setup is to run the macro against several, a score, dozens, hundreds, or thousands of SAS catalogs and build a SAS data set which identifies their bitage. After that, one may choose to copy AllCatalogs to a permanent SAS data set, or create a report from it. Or both.
Being a talented SAS programmer yourself, I would bet that you also do not like it when people tell you that you cannot do something with SAS. Right? Yea, it goes with the territory. How about posting a comment telling us about a particularly difficult SAS problem you encountered and the clever way that you resolved it? Bet you can’t do that.
Best of luck in all your SAS endeavors!
2 Comments
Thanks for sharing this contents. It helped me a lot.
An innovative approach and very helpful piece of code. The program executed without errors, but all my catalogs were coming up as unknown until I created a new catalog. Searching the catalog file with Notepad, I found W32_7PRO starting at column 225, preceded by my SAS version number. When I looked at the same place in my older catalogs, I found XP_PRO, which was my previous operating system. This also was preceded with an earlier SAS version number.
Therefore, you might have to add a few other SYSSCPL values. Look up SYSSCPL in the online help and you can see a list of values and would be able to separate into 32bit and 64bit. Your current value can be found in your initial signon log or in the SASHELP.VMACRO table.